前言

2026上半年有個個人OKR目標, 要學習GCP, 並且把學習紀錄登上鐵人賽
身為一個純前端, 我對雲端粗淺的理解是把專案build之後, 找個託管服務像是vercel, heroku, 有支援nodeJs的, 串好上版的設定, 可以推上去讓人訪問, 我就完工了
不過學習系統設計後, 理解一套服務在流量增加後，可能有load balancer, 水平擴展, 服務有gateway來限制訪問,..etc; 以及在公司內時不時有google提供的雲端訓練課程, 另外公司也會有接觸到上雲的部分, 這些經驗反而讓我非常困惑, 像是系統設計學到的一套架構, 和gcp上五花八門的服務, 以及公司裡會要向雲端管理部門請求資源的經驗, 三者像是有關聯又很像彼此平行, 以前上的線上課又常會上完後記憶開始fade out, 或是學一學卡關摸不出為什麼.
終於現在我可以和AI學習, 把碰到的問題和各種對步驟上的不解通通提出, 於是有了這個學習紀錄

在這個專案開始前, 我先和主管討論我要學gcp, 以我們部門來說, 最和gcp相關的就是對話機器人, 用來回答用戶的常見問題查詢(FAQ), 我們的方向不是要再蓋一次公司現存的機器人, 而是把一個當時google推出的技術dialogflow CX(後面遇到會再述)當作主要方向, 就先設定用戶是部門成員, 上來查OWASP的規範好了, 是常見弱點掃描的一個標準

而這個機器人agnet, 要存在gcp的服務上, 會需要哪些服務, 也就是我用來和gemini(免費版)討論的主題, 並且參加鐵人賽也是我上半年一大目標, 所以除了要實作, 我還要求gemini幫我在專案中切分30天份的主題, 讓我好用單元式的學習來增加知識和練習

Day1 核心服概覽

經過與主管討論和gemini收斂後, 學習的範疇可能分為幾大類

1. 基礎架構即代碼 (IaC)：自動化的靈魂

• Terraform：這是我們實現「一鍵部署」的核心工具。尤其我們的POC環境有設定定期會重置, IaC會幫助我們快速架構好環境

2. 成本與預算 (Billing)：燒錢要燒得有譜

• Billing & Budgets：雲端資源是按量計費的。我們會學習如何設定「預算警示」與監控，這不僅是保護個人錢包，更是模擬企業對財務治理（FinOps）的重視。

3. 運算 (Compute)：服務的棲身之所

• Cloud Run (Side Project 首選)：按量計費的 Serverless 服務。當沒人使用時自動歸零，是 POC 節費與前端轉向後端的首選。
• GKE (Google Kubernetes Engine)：企業級容器管理平台。模擬銀行生產環境追求的高可用性、負載平衡與自動擴展。

後來決定採用Cloud Run, 在探索上比較省

4. AI 與對話 (AI & Dialog)：機器人的大腦

• Dialogflow CX：專門處理複雜、多步驟的對話流。在 POC 中，它負責解析使用者意圖，並透過 Data Stores 定期爬取銀行 FAQ 內容, 也是本次POC的重點研究項目。
• Vertex AI：在 Side Project 中體驗 Gemini 模型或 RAG (檢索增強生成) 等尖端技術，這裡是開發中心。

後來發現這兩者只要擇一就好

5. 安全與身份治理 (Security & Governance)：金融業的命脈

• IAM (Identity and Access Management)：雲端權限的基石。管理「誰」可以對「什麼資源」做「什麼事」，落實最小權限原則。
• IAP (Identity-Aware Proxy)：POC 關鍵技術。取代傳統 Load Balancer，直接透過身份驗證（如 Google 帳號白名單）鎖定測試環境。
• Secret Manager：將 API Key 與資料庫密碼鎖進保險箱，避免金鑰在代碼或環境變數中裸奔。

6. 網路與連接 (Networking)：雲地的橋樑

• VPC (Virtual Private Cloud)：你在雲端的私有區域網路，所有服務的溝通邊界。
• Interconnect & Shared VPC：解析銀行如何透過實體專線實現混合雲，將雲端資源變為公司內網的延伸。

💡 學習資源 (已驗證)

• GCP 官方導覽 (Overview)：快速看過 Compute, Storage, Networking 的分類。
• Google Cloud 解決方案中心：搜尋 "Chatbot"，看看官方推薦的架構長什麼樣子。

GCP overview的摘要

1. 專案 (Projects) 是資源的「容器」與「邊界」

• 組織實體：所有你分配並使用的 GCP 資源都必須屬於一個專案。專案包含了設定、權限及描述應用的元數據。
• 隔離性：專案同時也是一個「命名空間 (Namespace)」。同一個專案內的資源通常可以輕鬆地協同工作（例如透過內部網路通訊）；但不同專案之間的資源預設是隔離的。
• 跨專案通訊：除非使用 Shared VPC（共享 VPC）或 VPC Network Peering（VPC 網路對等互連），否則專案無法直接存取另一個專案的資源。

2. 服務 (Services) 是存取資源的「途徑」

• 產品即服務：在雲端運算的環境下，原本被視為軟硬體的產品變成了「服務」。
• 功能提供：這些服務（例如 GKE、Cloud Run、Cloud SQL）提供了存取底層資源的管道。當你開發應用程式時，是透過「組合不同服務」來建構所需的基礎設施。

3. 資源 (Resources) 的階層與範疇

除了專案外，資源本身還有地理上的限制，這會影響它們如何被分配與取用：

• 全球資源 (Global)：可被同一個 Universe 內任何區域的資源存取，例如網路 (Network)、磁碟映像檔。
• 區域資源 (Regional)：僅能被同一個區域 (Region) 的資源存取，例如靜態外部 IP 位址。
• 區域空間資源 (Zonal)：僅能被同一個區域空間 (Zone) 的資源存取，例如 VM 實體與磁碟。

總結

• 分配單位：資源必須隸屬於 Project。
• 通訊限制：Project 間互不相通，除非透過 Shared VPC 或 Peering。
• 存取介面：我們是透過 Service (產品) 來管理與調用 Resource。

這樣的理解對於 Day 2 要討論的「資源階層」非常重要，因為它奠定了「誰能管什麼」以及「資源如何被隔離」的基礎。

本日練習

建立專案

新增專案後 個人專案通常選無組織

過一陣子專案建立後就可以切換過去了

使用console, 點擊右上角的啟用cloud shell

console shell連線後輸入 gcloud auth list

可以查詢到現在的用戶(自己)

輸入 gcloud projects list 顯示專案列表

如果是第一次操作應該會觸發要enable API

允許後會跑一陣子 再呼叫一次 projects list 應該就可以看到所有的projects列表了

不過呼叫api 使用服務就會開始考慮到收費的問題

day2我們就來理解預算的控制 還有免費的使用額度吧